NSXの分散ファイアウォールでインターネット向けの通信を制御する

NSXの分散ファイアウォールでインターネット向けの通信を制御する

分散ファイアウォールの概要、NSXタグによる動的なグループ化、このグループに基づく分散ファイアウォールルール設定などがざっくりわかるブログです。
Clock Icon2023.12.07

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

大家好,AWS事業本部の西野です。

分散ファイアウォール(DFW)とは

分散ファイアウォール(DFW/Distributed Firewall)はVMware NSXが提供するファイアウォール機能のひとつです。この分散ファイアウォールは、コンピュートゲートウェイ(CGW)や管理ゲートウェイ(MGW)に適用される境界型のファイアウォールとは異なり、仮想マシンのvNIC単位で機能するファイアウォールです。AWSの利用経験がある方はVPCのセキュリティグループと似たような機能であると考えるとイメージを捉えやすいはずです。

分散ファイアウォールの概要についてもう少し知りたい方は以下のVMware Japan Blogなどをご覧ください。

NSX-T Data Center NSX 分散ファイアウォールとは - パート1 - VMware Japan Blog

インターネット向けの通信制御をDFWで実行するメリット

VMware Cloud on AWS SDDC内の仮想マシンからインターネット向けの通信を制御したい場合、必ずしもDFWを使用する必要はありません。以下のブログではコンピュートゲートウェイを用いた制御を行っています。

[VMware Cloud on AWS] 仮想マシン単位でインターネットへの接続を許可する | DevelopersIO

しかしながら、たとえば、NSXの機能の一つである FQDN Filtering はMGWやCGWでは使用できず分散ファイアウォールのルールにおいてのみ使用できます。

In VMware Cloud on AWS, NSX FQDN filtering is supported only for use with Distributed Firewall rules. It cannot be used with MGW or CGW firewall rules.
VMware Cloud on AWS Networking and Security』より引用

もともとこの FQDN Filtering は追加費用が必要なアドオンによって提供されていたのですが、VMware Cloud on AWS Advanced エディション1ではVMware Cloud on AWSの標準サービスとして利用可能になることが発表されています。

したがって、CGWにおいては大まかなルールを設定し、プロトコルや宛先のFQDNなどをもとにした細かな制御は分散ファイアウォールで行うほうがよいと私は考えています。
(ただし、2023年12月現在、最新版のSDDCをデプロイした場合でもこのFQDN Filteringを使用することはできません。実装が待ち遠しいです。)

やりたいこと

今回の構成図がこちらです。

上図の仮想マシン Development01 からのみインターネット向けの通信を許可することを目的に以下の設定を実施していきます。

  • 各仮想マシンにNSXタグを付与する
    • Development01: True (Scope: InternetAccess)
    • Development02: False (Scope: InternetAccess)
  • インターネットアクセスを許可する仮想マシンのグループを作成する
    • NSXタグによる動的なグルーピングを利用
  • 分散ファイアウォールでこのグループに含まれる仮想マシンのインターネット向け通信を許可する
    • 明示的に許可された通信以外をすべてDropするようデフォルトルールを変更する
    • インターネット向け通信を許可するルールを追加する
  • CGWではすべてのアウトバウンドトラフィックを許可する

手順

仮想マシンの作成およびOSインストールは済んでいる前提とします。

仮想マシンへのNSXタグ付与

NSXコンソール → インベントリ → 仮想マシン → 対象仮想マシンの左部ケバブボタン → 編集をクリックします。

ここではまずは Development01 を対象にしています。

タグとしてTrue(Scope: InternetAccess)を入力し、右部の+マークをクリックします。タグが追加されるのを確認できたら保存をクリックします。

NSXタグのScopeはAWSタグのキーと同様のものであると考えていただければOKです。

同様の手順で Development02 にはFalse(Scope: InternetAccess)を設定し次のステップに進みます。

グループの作成

インターネットアクセスを許可するグループを作成しましょう。

NSXコンソール → インベントリ → グループ → コンピューティンググループ → グループの追加をクリックします。

グループ名をつけます。ここではInternetAccess-VMsとしましょう。続いて右側の「設定」をクリックします。

このメンバーの設定の画面では対象仮想マシンをグループに含めるための条件を定義していきます。今回は仮想マシンのタグがTrueでありScopeがInternetAccessと等しい仮想マシンをIntenetAccess-VMsに含める定義をします。条件の指定を終えたら「適用」をクリックします。

タグの他にもIPアドレス / ネットワークアドレス / Active Directory グループなどを基準にしたメンバー設定が可能です。

一つ前の画面に戻るので「保存」をクリックします。これでグループの設定は完了です。

分散ファイアウォールの設定

具体的な設定に入る前に分散ファイアウォールの評価について少し解説します。

こちらが分散ファイアウォールの設定画面です。分散ファイアウォールのポリシーはカテゴリと呼ばれるグループによって分類されており、このカテゴリには評価の優先順位が存在します。(イーサネット>緊急>インフラストラクチャ>環境>アプリケーション の順番で評価される)

各カテゴリにどのようなポリシーを含めるべきかについては以下のドキュメントをご参照ください。
分散ファイアウォール ルールの追加または変更

また、カテゴリ内においては上位の(上に配置されている)ポリシーから順番に評価されていきます。

以上の説明を踏まえた上で、SDDC作成時から存在するデフォルトのポリシーを見ていきます。

アプリケーションカテゴリの最下位にはDefault Layer3 Sectionと呼ばれるポリシーが存在します。また、当該ポリシーの中には、Default Layer3 Ruleと呼ばれる送信元・宛先・サービスのすべてが任意でありかつアクションがAllowのルールが設定されています。

つまり、SDDC作成後のデフォルト状態において、分散ファイアウォールはすべての通信を許可してしまうということです。

今回は分散ファイアウォールで明示的に指定した通信のみを許可させたいので、まずはこのDefault Layer3 Ruleを変更しましょう。

NSXコンソール → セキュリティ→ 分散ファイアウォール → カテゴリ固有のルール → アプリケーション(カテゴリ)をクリックします。Default Layer3 Section内部のDefault Layer3 Ruleのアクションを Drop に変更し、「発行」をクリックします。これにより、分散ファイアウォールにおいて明示的に指定されていない通信はすべて Drop されるようになりました。

続いてインターネットアクセスを許可するためのルールを設定していきます。

同じ画面の「ポリシーの追加」および「ルールの追加」をクリックし新規のポリシーとルールを追加します。送信元として先の手順で作成したグループInternetAccess-VMsを指定した上で、宛先やサービスを任意とし、最後に「発行」をクリックします。

コンピュートゲートウェイの設定

分散ファイアウォールとは異なり、コンピュートゲートウェイはデフォルトの状態ですべてのアップリンクに対する通信を Drop します。インターネット向けの通信を通すようにルールを変更しましょう。

NSXコンソール → セキュリティ→ ゲートウェイファイアウォール → コンピュートゲートウェイ → 「ルールを追加」をクリックします。送信元・宛先・サービスを任意とした上で、適用先としてInternet Interfaceを選択します。その後、「発行」をクリックしてルールを適用しましょう。

動作確認

最後にとても地味な動作確認をします。
vSphere Clientから各仮想マシンのWebコンソールを起動し、8.8.8.8に対してpingを飛ばしてみます。

Development01

  • Development01にはタグ True(Scope: InternetAccess) が設定されている
  • このタグで仮想マシンがグループ化されている
  • 当該グループに含まれている仮想マシンからインターネット向けの通信が分散ファイアウォールで許可されている
  • CGWのInternet Interfaceに適用されたルールがすべての通信を許可している

したがって、Development01からはpingが通ります。

Development02

先述の条件を満たしていないDevelopment02からは当然pingが通りません。

終わりに

このブログがほんの少しでも世界を良くできれば嬉しいです。
AWS事業本部の西野 (@xiyegen) がお送りしました。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.